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ABSTRACT 


The American Institute of Aeronautics and 
Astronautics has Initiated a Committee on 
Standards for Artificial Intelligence. 
Presented here are the Initial efforts of 
one of the working groups of that 
committee. The purpose of this paper Is 
to present a candidate model for the 
development life cycle of Knowledge Based 
Systems. The Intent Is for the model to 
be used by the Aerospace Community and 
eventually be evolved Into a standard. 

The model Is rooted In the evolutionary 
model, borrows from the spiral model, and 
Is embedded In the standard Waterfall 
model for software development. Its 
Intent Is to satisfy the development of 
both stand-alone and embedded KBSs. The 
phases of the life cycle are detailed as 
are and the review points that constitute 
the key milestones throughout the 
development process. The applicability 
and strengths of the model are discussed 
along with areas needing further 
development and refinement by the 
aerospace community. 


1.0 INTRODUCTION 


This paper presents a model for the life- 
cycle development of knowledge-based 
systems. The Artificial Intelligence 
Software Engineering (AISE) Model Is an 
outgrowth of an effort by an AIAA 
committee on standards for AI. This 
committee was convened In early 1989 to 
explore the potential for developing 
various standards or guidelines for AI. 
Three working groups were formed to 
explore definitions and lexicon compila- 
tion, tools standardization feasibility, 
and development of life-cycle guidelines. 
The course of our approach Is to develop 
candidate guidelines, disseminate to the 
community for feedback, and slowly evolve 
to standards as acceptance of the 


products grows. It Is In that spirit 
that this paper presents the AISE model 
to the aerospace community for Its 
feedback. 

During the past ten years, the Knowledge- 
Based System (KBS) branch of Artificial 
Intelligence (AI) has matured con- 
siderably. Many small prototype systems 
have been successfully developed and 
Implemented. Larger KBSs are much more 
complex and have been Implemented at a 
slower rate. The organizations at the 
leading edge of using AI, ones that have 
been developing KBSs and applying them, 
are looking at the Integration of KBSs 
Into the mainstream of their computing 
environments. This Is taking a more 
traditional total systems approach to AI, 
making the KBS an Integral part, not a 
standalone tool. With the perspective of 
a systems approach comes the need for 
more rigorous development and Integration 
methodologies. This need, coupled with 
general community's desire to control 
costs and schedules. Is the Impetus for 
the AISE model. 

The objective of the AISE model Is to 
provide a flexible framework for the 
development of a KBS (either standalone 
or integrated) with meaningful milestones 
and reviews that support the control of 
technical, cost, and schedule dimensions 
of a program. To achieve this objective, 
the model borrows the best attributes of 
the evolutionary software development 
model and some of the spiral model 
concepts and embeds them in the Waterfall 
model for software development. 


2.0 SOFTWARE DEVELOPMENT MODELS 


Several basic phases are inherent parts 
of any software (Including AI) 
development program: Problem conceptual- 

ization/definition; system design; 
system development; testing; Integration; 
and maintenance and enhancement. The 
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sequence In which these are carried out, 
the amount of emphasis/effort given each 
phase, and the controls associated with 
execution of the work combine to define a 
life-cycle model . 

The Waterfall model, shown In Figure 1, 
Is the most widely used In one variation 
or another. In the concept definition 
phase, studies and trades are conducted 
to define the system to be built. As a 
result, this phase culminates in a 
minimum of system requirements, top-level 
design specifications, and an operational 
concept. Next, a Preliminary Design 
Phase fleshes out the specifications and 
top-level design. Interfaces and data 
bases are specified, critical methods 
(such as special algorithms) are 
addressed, and test plans are conceived. 
The Preliminary Design is followed by a 
Detailed Design phase that finalizes the 
design and specifications. Simulations 
and prototyping are used to test the 
design, and test plans and operations 
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Figure 1. Standard Software Development 
Life-cycle 

manuals are developed. Once design Is 
complete, the software Is coded/developed 
according to It and the specifications. 
As the software components are developed, 
they are tested and hierarchically 
validated and Integrated to form the 
overall system. Once the system Is 
accepted by Its users, there Is usually a 
long life of maintenance and upgrades 
during Its operation. 



Figure 2 . Spiral Model of the Software Process 


The Spiral model, developed at TRW and 
shown In Figure 2, follows a different 
sequence. Once a problem is conceived, a 
series of prototypes is used to address 
the areas of highest risk in order of 
difficulty. Once all the parts of the 

system are well understood and the 
prototypes have developed a preliminary 
design, this model picks up the back 
phases of the Waterfall model to finish 
the product. A key characteristic of the 
Spiral model Is the non-uniform 
maturation of system parts. 


Another methodology for software 
development, one often used for AI, Is 
the Evolutionary Model. Under this 
model, software is developed and tested 
Incrementally for most of Its life cycle. 

Figure T provides a comparison of the 
models discussed. Given are the most 
appropriate situations for the 
application of each of the models, along 
with their strengths and weaknesses. If 
we examine the chart In light of some key 
characteristics of an aerospace KBS 
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development, we are lead to the 
conclusion that a hybrid model Is needed. 
Three characteristics of KBS development 
are essential for aerospace applications: 
1) There is usually uncertainty In the 
scope of the problem and Its appropriate 
solution; 2) the knowledge engineering 
process Is Inherently an evolutionary 
process; and 3) projects tend to have 


tight cost and schedule budgets. These 
three Items point to a model that has 
flexibility and Is evolutionary In nature 
while at the same time has a firm 
structure to control the development 
process. The Artificial Intelligence 
Software (AISE) model Is designed to meet 
these needs. 


MODELS 

APPLICABILITY 

STRENGTH 

WEAKNESS 

WATERFALL 

{SPECIFICATION 

DRIVEN) 

■ LARGE SCALE DEVELOPMENT 

• WELL DEFINED PROBLEMS 

• CONSTRAINED RESOURCES 

• GOVERNMENT REQUIREMENT 

•RIGOROUS STRUCTURE 

• WORKS TO CONSTRAINTS 

• GOOD DEVELOPMENT 
VISIBILITY 

• DIFFICULT TO CHANGE 

• UNIFORM PROGRES OF ALL 
COMPONENTS 

• DOES NOT ACCOMODATE 
EVOLUTIONARY DEVELOPMENT 

SPIRAL 
(RISK DRIVEN) 

• MEDIUM SIZE DEVELOPMENT 
. KNOWN RISKY AREAS 
. UNCONSTRAINED 
RESOURCES 

• ACCOMOOATES NON 
UNIFORM DEVELOPMENT 

• CONCENTRATE ON CRITICAL 
COMPONENTS 

• ADAPTIVE TO OTHER 
MODELS 

• LIMITED COST AND SCHEDULE 
CONTROLS 

• LIMITED DEVELOPMENT OF 
MILESTONES AND REVIEWS 

• LIMITED SPECIFICATION AND 
DOCUMENTATION DEVELOPMENT 

EVOLUTIONARY 

(PROTOTYPE 

DRIVEN) 

• SMALL TO MEDIUM SIZE 

• ILL DEFINED PROBLEMS 

• UNCONSTRINED RESOURCES 

‘ INCREMENTAL BUILD 
• EASY TO CHANGE DIRECTION 

• LIMITED COST AND SCHEDULE 
CONTROLS 

• LIMITED CONTROL OF REQUIREMENTS 

• DIFFICULTY SCALING UP 

• NO VISIBILITY WTO PROCESS 


Figure 3. Software Development Models 


3.0 ARTIFICIAL INTELLIGENCE SOFTWARE 3.1 Problem Identification 

ENGINEERING (AISE) MODEL 


The AISE model, shown In Figure 4, 
focuses on the KBS element of a system as 
an area of high risk. It drives the 
development to be at the same level of 
maturity for Its components at each major 
milestone, thus providing for process 
control. 

The AISE phases and their relations to 
each other are shown In Figure 4. In the 
following sections, we discuss the 
objectives, activities, and results of 
each phase. 
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Figure 4. The A I Software Engineering 
(AISE) model 


Objectives: Analyze and define problem 
elements that are suitable for KBS 
solution. 


Activities: 

1. Isolate problem areas that are 

potentially suitable for KBS 
solution 

2. Perform trades to determine whether 

KBS Is the best solution compared to 
other techniques 

3. Perform cost/benefit analysis 

4. Draft development plans. Including 

key participants needed 

Results/Products: A well defined and 

justified KBS application with a plan for 

Its development 


3.2 Prototyping 


Objective: Develop a full -capability 
prototype of the KBS element along with a 
detailed design for its target 
Implementation 
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Activities: A series of three 

prototyping Iterations and six reviews 

1. Evolve a prototype to a full 
knowledge set 

2, Test prototype during development 

3, Develop documentation 

4. Design target environment 

5* Review prototyping progress 


REQUIREMENTS 
PROTOTYPE 
CONCEPT REVIEW 

A 


DEVELOPMENT / DEVELOPMENT 


Results/Products: A fully developed 

product prototype of the KBS, the design 
for Its target environment, and the 
associated support documentation. 

The prototyping phase Is the most 
critical In building a KBS, and 
accordingly It Is the heart of the AISE 
model. The content and control of the 
work done In this phase will determine 
the success of the system being built. 
Figures 5, 6, and 7 show details of the 
review milestones associated with each of 


DESIGN 

CONCEPT 

REVIEW 

A 



B PC R PURPOSE: 
ACERTAIN WE KNOW ALL 
TWE PIECES NEEDED 


DCR PUHPOSE : 

EVALUATE DESIGN CONCEPTS AND 
INITIAL PROTOTYPE 


ASSESS : 

- REQUIREMENTS SET COMPLETENESS 

- KE PROGRESS 

- TOOLS SELECTION 

- RISK IDENTIFICATION 


EVALUATE : 

- OPERATIONAL CONCEPT 

- FUNCTIONAL BREAKDOWN 

- INITIAL INTERFACES 

- REQUIREMENTS FOR KNOWLEDGE SET, 
TOOLS AND PERFORMANCE 


Figure 5, Requirements Prototype 
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PROTOTYPE 
REVIEW 
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PRELIMINARY 

DESIGN 
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DEVELOPMENT 


DEVELOPMENT 


Z 


IDPR PUHPOSE : 

OBTAIN DESIGN FEEDBACK FROM 
USERS AND REVIEWERS 


PDR PURPOSE : 

EVALUATE FULL DESIGN AND ITS 
READINESS FOR PRODUCT 
PROTOTYPING 


ASSE33 : 

INITIAL DESIGN 
PRELIMINARY INTERFACES 
RISK MITIGATION 
DEVELOPMENT PROCESS 


EVALUATE : 

- FUNCTIONAL PROTOTYPE 

- FULL KBS DESIGN 

- USER INTERFACES 

- SYSTEM INTERFACES 

- UPDATED OPS CONCEPT 

- TEST PLANS 


Figure 6. Design Prototype 
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IPPR PURPOSE : 

ASSESS PRODUCT CAPABILITY TO 
MEET REQUIREMENTS 


CDR PURPOSE : 

REVIEW FULL CAPABILITY PROTOTYPE 


ASSESS : 

- PRODUCT PERFORMANCE 

- TEST PROCEDURES 

- ENHANCEMENT NEEDS 


EVALUATE : 

PRODUCT PROTOTYPE 

TARGET ENVIRONMENT D E SIG NIM PL E MENTATION 
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Figure 7. Product Prototype 
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the prototyping stages and the contents 
expected at each review. 

3.3 Development/Integration: 

Objective: Embed the KBS Into its target 

environment. 

Activities: 

1. Port KBS to Intended host 
environment (and, if applicable, 
language) 

2. Integrate with system components 
that are external to the KBS through 
interfaces (I/F) 

3. Implement Integrated user I/F 

4. Develop documentation 

Results/Products: An Integrated KBS In 

Its target environment 

3.4 Test and Evaluation 

Objective: To ensure that the overall 

system works according to specifications 

and meets Its requirements 

Activities: 

1. Perform hierarchical tests with 

greater levels of Integration 

2. Perform regression tests to check 

against standalone KBS prototype 
results 


3. Evaluate overall system performance 

4. Validate that the system meets 
requirements 

5. Perform acceptance testing 

Results/Product: Completed system ready 

for delivery to user 

3.5 Operations and Maintenance: 

Objective: Apply system to Its intended 

use 


Activities: 

1. Routine operation of system 

2. Debugging as required 

3. Enhancements as the needs come up 

Result/Product: A gracefully maturing 

system 

The life-cycle of the AISE model has been 
planned to be compatible with the 
Waterfall model. This was done 
deliberately since many aerospace 
programs are mandated to use a variant of 
the Waterfall model (many are requested 
to use the 2167A standard). Figure 8 
shows how the AISE model folds into the 
Waterfall. The review milestones align 
precisely with the completion of the 
prototyping phases and the two merge 
during the development phase. 


WATERFALL MODEL 


PCR 

V 


CONCEPT 

DEFINITION 


PDH 

V 


PRELIMINARY 

DESIGN 




DETAILED 

DESIGN 


DEVELOPMENT 


ACCEPTANCE/DELIVERY 

V 


TEST 


DEVELOPMENT/ 

INTEGRATION 


MAINTENANCE 


PROTOTYPING 


PROB. 

ID. 


At SOFTWARE ENGINEERING MODEL 


Figure 8. Integrated/Embedded Methodology 
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4,0 CONCLUSIONS 


In order to Integrate KBSs Into the 
mainstream of software development and 
aerospace applications, a more rigorous 
development methodology Is needed. The 
most popular software development models 
have been examined for their 
applicability and characteristics. A new 
hybrid, the AISE model. Is proposed for 
KBS development. The AISE model provides 
flexibility up front for evolution of a 
knowledge base. At the same time, it 
provides visibility Into development 
through a series of reviews. One of the 
features of the AISE model Is the uniform 
(at milestones) development of all 
components of the KBS. This uniformity 
allows for meaningful development of 
requirements and specifications for the 
whole system, which in turn provides the 
mechanisms for technical, cost, and 
schedule controls. Finally, the AISE 
model can be neatly merged with the 
Waterfall model making the AISE model 
applicable and compliant with most 
Government software acquisition 
requirements. 
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